In todays software industry there is a constant struggle between time, money and quality. You can never ship soon enough. To mitigate this problem many have started to write automated software tests, which test for software errors in response to various inputs. The most natural approach to this was to write linear, static test cases, collect these test cases into test suits, and then run these software test suits. As the tests are executed, the test results are collected for analysis.
The linear tests take a long time to run and they are usually only run toward the end of the development cycle. These linear tests are also expensive in terms of development costs. Additionally, their linear static nature results in testing the same paths through the software under test time after time. In other words, such linear tests always do the same thing, in the same order and can only do exactly what the test developer has programmed them to do. This also puts a lot of stress on the test developer because he or she needs to come up with numerous different combinations of inputs to the software (called test case design) in order to maximize the likelihood of identifying potential errors. However, nontrivial software often has so many combinations of input that it becomes impossible to cover them all or to even pick the most important combinations, which diminishes the quality of test case design. Additionally, conventional tests only run during a test phase, during which time the hardware on which the software under test runs can not be used for other purposes. Conventional software testing also delivers results too late in the development cycle. Finally, one change in the software under test requires many linear static test cases to be updated, which complicates test case maintenance and may result in many false positives.